セッションマネージャー越しにSSHアクセスすると何が嬉しいのか

なにそれ？と思われた方、ぜひ読んでいってください。

#SSH

#Amazon EC2

#AWS Systems Manager Session Manager

#AWS Systems Manager（SSM）

#AWS

かずえ

2020.08.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

セッションマネージャー越しにSSHアクセスする構成のメリットについて考えてみました。

なにそれ？

公式ドキュメントでいうと以下内容のことです。

Step 8: (Optional) Enable SSH connections through Session Manager

もう少し詳しく

まず、クライアントはセッションマネージャーを使ってアクセスしたいインスタンスにアクセスします。

もう少しこの部分を具体的に説明すると、クライアントがアクセスしているのはインスタンスではなく、SSM(Systems Manager)のエンドポイントです。そして、アクセス先インスタンス内のSSM Agentがポーリングアクセスしていて、こちらを通じてアクセスしています。

そして、この接続の先で、SSH接続し直しているイメージになります。これが今回扱う「セッションマネージャー越しにSSHアクセス」です。

わざわざSSHしなおす必要なくない？セッションマネージャーでもう接続できてるしコマンド打てるよ

そうですね。わざわざSSHしなおすメリットは 2つあると思います。

鍵認証がそのまま使える

従来のSSH接続そのまま、公開鍵認証ができます。セッションマネージャーだけだとできないです。あ、パスワード認証もできますよ。

操作感が(ほとんど)同じ

セッションマネージャーなしでSSHする場合、こんな感じのコマンドですよね。

$ ssh -i (鍵ファイルのパス) ec2-user@(インスタンスのIPもしくはパブリック DNS(FQDN))

このセッションマネージャー越しのSSHアクセスの場合、アットマーク以降の記述がインスタンスIDに変わるだけで接続可能です。

$ ssh -i (鍵ファイルのパス) ec2-user@(インスタンスのID)

また、SCPも同じ感じで使えます。

$ scp -i (鍵ファイルのパス) (ローカルファイルのパス) ec2-user@(インスタンスのID):~/

他に、細かい点ですが、セッションマネージャーだと接続ユーザーがssm-userになりますが、この構成だとec2-userのままにすることができます。

使い方(ほぼ)そのままで、セッションマネージャーのメリットを受けられるわけですね。

セッションマネージャーのメリットって何？

色々あります。

IAMで認証・認可ができる

セッションマネージャーはSSMの機能の一つなので、もちろんIAMによる権限制御ができます。以下が今回の構成を利用できるIAM Policyの一例です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ec2:*:*:instance/(インスタンスID)",
                "arn:aws:ssm:*:*:document/AWS-StartSSHSession"
            ]
        }
    ]
}

そして今回の構成の場合、前述のとおり従来の鍵認証もそのまま使えます。IAM認証と鍵認証、二重で認証が可能です。

複数人の間での使いまわしを抑止するために、鍵認証に使うキーペアは人数分用意して設定するべきです。が、人の出入りの度に鍵の設定を変更するのは煩雑です。この構成ならIAM認証もできるので、（セキュリティポリシーによりますが、）キーペアは共有しても良いかもしれません。

SSHポートへのインバウンドアクセス許可設定（いわゆるポート空け）が不要

セッションマネージャーなしでSSHする場合、クライアントからインスタンスまでの経路を確保する必要があります。インスタンスへの22番ポートへのインバウンドアクセスをセキュリティグループなどで許可する必要があります。

今回のこのセッションマネージャー越しのSSHですと、クライアントとインスタンス間の通信は前述のとおりセッションマネージャーで行ないます。その際、インスタンスのインバウンドアクセス許可設定は何も必要ありません。（443番アウトバウント許可のみ必要です。SSM AgentがSSMエンドポイントに対してポーリング行なう際に使用します。）

クライアントのIPを限定したい場合はどうするの？

セッションマネージャーなしでSSHする場合、インバウンドセキュリティグループルールの送信元でCIDRを指定して、特定のIPからのみ接続許可できます。この方法は今回の構成では使えません。IP制限したい場合はどのようにすれば良いでしょうか？

前項の「IAMで認証・認可ができる」で書いたとおり、IAMで細かな認可設定ができます。Condition句でIPの条件をつければ良いです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ec2:*:*:instance/(インスタンスID)",
                "arn:aws:ssm:*:*:document/AWS-StartSSHSession"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "147.xx.xx.xx/32"
                    ]
                }
            }
        }
    ]
}

ログが取れる

セッションマネージャーのコンソールから履歴が確認できます。
(CLIでもできます。$ aws ssm describe-sessions --state History)

また、CloudTrailでのロギングも可能です。セッション開始時に「StartSession」というeventNameのイベントが記録されます。

CloudTrailでロギングできるということは、そのイベントをCloudWatch Eventで拾って他の様々なAWSサービスの起動につなげることができるということです。例えばSNSトピックを紐付けてメール通知することができます。

注意点としては、あくまでセッションマネージャーのログを取っているものなので、その上で実行されるSSHのコマンド履歴が取れるわけではありません。

参考情報

鍵認証使えるって言っても、クライアントがSSH使わずセッションマネージャーだけで接続したら鍵認証使わなくて済むやん。SSH(セッションマネージャー越しのSSH)を強制することってできるの？

できます。IAM Policyを工夫しましょう。ssm:SessionDocumentAccessCheckを使います。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ssm:StartSession",
            "Resource": [
                "arn:aws:ec2:*:*:instance/(インスタンスID)",
                "arn:aws:ssm:*:*:document/AWS-StartSSHSession"
            ],
            "Condition": {
                "BoolIfExists": {
                    "ssm:SessionDocumentAccessCheck": "true"
                }
            }
        }
    ]
}